Fedora rawhide check #121
Fedora rawhide check #121
Conversation
Requires fedora-repos-rawhide installed. Tests whether current Fedora rawhide points to correct release key. Creates also rawhide+1 and rawhide-1 links to preceding releases. Might be used by mock-core-configs package directly.
Upcoming rawhide release key and previous release key is often required by various tools. Prepare symlinks, which can be updated by script on next Fedora branching.
|
It is also related to bug https://bugzilla.redhat.com/show_bug.cgi?id=2305309 |
|
This is already handled by https://github.com/rpm-software-management/distribution-gpg-keys/blob/main/.github/workflows/fedora-repos.yml And check the dates. The new GPG key was added here very shortly after the key was created by relengs. |
|
This is meant to solve the problem: rpm-software-management/mock#1342 https://pagure.io/releng/issue/12001 was meant to update the release process so we never forget, but I assume it needs revamping. |
|
@xsuchy That workflow checks only addition of new GPG key. But does not trigger any action when rawhide is switched to new release. Even though it were updated quickly, it still has broken mockbuild on rawhide branch, because the update was not done together with mock-core-configs (and fedora-repos). Ideally we should have just one source of truth, which change at single place would be enough to switch to N+1 release in all other tools. The less packages, where that change needs to happen, the better. This is one step to remove the need to update releasever in mock-core-configs. Because it uses the key from this package anyway and that change needs to happen here first. It does not count when key is added, but when the update hits the stable. That unfortunately were not as quick and multiple people complained on Friday at devel matrix channel. That could be avoided if change of mock-core-config did not have to match change in distribution-gpg-keys. |
Obtain rawhide_release from spec file and check our rawhide key points to matching release.
|
These symlinks should avoid the need to change mock-core-configs/etc/mock/templates/fedora-rawhide.tpl and rawhide-eln.tpl in rpm-software-management/mock@1d000d9#diff-6d85f049d29a9ebeda1e02d48fb369982d6410ba63c64306001e1f41f8a3c4dd. Which needs to match change here and in current way needs to part of the same update, probably using side tags. |
|
That is, these changes are needed because rawhide_gpg_keys macro creates rawhide+1 and rawhide-1 key links. If this package provides these links, then only this package is responsible for the change and releasever adjusting from mock-core-configs can be removed. Replaced by just something like: But wait. I have not noticed eln uses different values than rawhide. rawhide uses |
fedora-eln template uses rawhide+0, rawhide-1 and rawhide-2 keys. Unlike rawhide +1 and -1. Add additional managed link too.
GitHub worflow already contains similar check. Use similar also for checking rawhide release here. It should work on any distribution having git and awk installed, for example ubuntu image.
|
This is related to problem rpm-software-management/mock#1338, which needs similar workarounds also in mkosi. Having this at key provider might provide decent workaround. |
This is attempt to reduce number of packages, which need to be updated after new release is branched from current rawhide. This were initiated by broken mock during branching, because updates were needed together in two separate components:
I think that is in fact not necessary, because mock-core-configs uses releasever only to compute key path one higher and one lower than current rawhide. If that is provided directly by this package, then mock-core-config can use symlink provided and change only when they want to add new release into collection. This package update would fix also mock rawhide.